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Executive  Summary 


The  Department  of  Defense  (DoD)  manages  the  procurement,  distribution,  and 
rep^lir  of  approximately  5  million  items.  Associated  with  the  items  are  approxi¬ 
mately  107  million  sheets  of  engineering  data.  To  physically  preserve  these  data 
and  to  make  them  universally  available,  DoD  has  undertaken  a  large-scale  project 
to  convert  them  to  electronic  media. 

Just  because  product  data  are  stored  electronically  does  not  mean  they  become 
more  useful.  The  choice  of  product  data  format  determines  the  degree  of  useful¬ 
ness.  The  approach  taken  by  DoD  is  to  scan  existing  drawings  into  electronic 
pictures  called  raster  images.  While  this  approach  is  acceptable  for  preserving  past 
data,  it  is  not  sufficient  for  new  or  reengineered  product  data,  and  it  is  not  com¬ 
patible  with  modem,  computer-aided  engineering  and  manufacturing  technolo¬ 
gies.  Those  modem  technologies  store  product  data  in  a  variety  of  formats,  known 
collectively  as  vector  formats. 

DoD  recognizes  this  and  has  formulated  a  long-term  goal  of  representing  its  prod¬ 
uct  data  in  a  neutral  vector  format  defined  by  an  international  standard.  That  stan¬ 
dard,  however,  is  incomplete  and  not  yet  supported  by  conunercial  mechanical 
engineering  software.  Therefore,  DoD  requires  a  near-term  transition  strategy  for 
storing  its  product  data  in  one  or  more  currently  available  vector  formats  while 
awaiting  the  international  standard  to  mature.  We  examined  the  available  product 
data  formats  for  mechanical  and  stractural  items,  such  as  valves  and  bushings. 
Although  our  emphasis  was  on  the  data  formats  required  by  the  Defense  Logistics 
Agency  for  procuring  spare  parts,  those  formats  are  important  throughout  the 
product  life  cycle.  Product  life-cycle  activities  producing  or  requiring  product  data 
include  initial  design,  production,  assembly,  testing,  training,  and  maintenance. 

Before  defining  the  product  data  alternatives  DoD  could  follow,  we  sought  to  un¬ 
derstand  the  capabilities  and  trends  in  computer-aided  design,  engineering,  and 
manufacturing.  To  this  end,  we  conducted  a  market  survey  of  seven  leading  soft¬ 
ware  products:  AutoCAD,  CATIA,  I-DEAS,  Pro/Engineer,  SmartCAM, 
SURFCAM,  and  Unigraphics.  We  noted  their  capabilities  in  areas  such  as  mod¬ 
eling  capability,  modeling  engine  used,  paramedics,  tolerencing,  engineering 
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analysis,  product  data  management,  and  data  exchange.  Many  of  the  packages  of¬ 
fer  robust  capabilities  in  these  areas.  The  associated  competition  is  driving  in¬ 
creased  product  integration  and  frequent  enhancement.  Today’s  industry 
standards,  for  neutral  product  data  exchange,  however,  do  not  reliably  capture  all 
the  essential  data  for  design  and  manufacture.  Also,  the  rate  at  which  the  com¬ 
mercial  software  is  improving  and  adding  capability  relative  to  the  standards,  is 
not  generally  appreciated.  For  example,  some  relatively  new  but  widely  used  fea¬ 
tures,  such  as  parametrics  and  design  constraints,  are  not  yet  included  in  the  stan¬ 
dards. 

With  an  understanding  of  commercial  engineering  software  capability,  we  formu¬ 
late  alternatives  by  which  DoD  could  format  its  product  data.  The  status  quo  is  a 
two-dimensional  raster  format.  Alternatively,  data  could  be  stored  in  two- 
dimensional  or  three-dimensional  vector  formats.  Also,  those  vector  formats  could 
be  proprietary  (defined  and  owned  by  a  company)  or  neutral  (defined  by  industry 
standard).  We  also  include  an  alternative  derived  from  vector  format  based  on 
three-dimensional,  neutral,  machine  instructions.  Each  of  these  approaches  has  its 
economic  and  technical  advantages. 

Conceptually,  three-dimensional,  neutral,  vector  format  is  the  most  useful  and  de¬ 
sirable  format  because  it  contains  the  most  complete  product  representation  and  is 
independent  of  the  software  used.  Due  to  the  current  lack  of  robust  standards, 
however,  we  recommend  that  DoD  consider  some  combination  of  two- 
dimensional  and  three-dimensional  proprietary  formats  until  the  standards  mature. 
There  is  no  single  “best”  format  that  DoD  should  use.  The  selection  of  a  format 
depends  on  the  commodity  (for  some  products  two-dimensional  format  is  ade¬ 
quate,  while  others  require  three);  the  software  in  place  at  DoD  engineering  cen¬ 
ters  and  their  contractors;  and  economic  considerations  (frequency  and  dollar  level 
of  activity  related  to  the  product). 

DoD  does  not  need  or  collect  product  data  for  all  items  it  buys.  DoD  typically 
does  not  collect  product  data  for  sole-source  items  and  items  that  are  to  be  main¬ 
tained  via  contractor  logistics  support.  The  issue  of  what  data  to  collect  and  in 
what  form  to  collect  them  pertains  to  items  that  DoD  intends  to  reprocure  com¬ 
petitively  or  where  the  product  data  are  needed  for  downstream  activities,  such  as 
training  or  testing.  For  these  items,  we  recommend  that  DoD  take  some  immediate 
actions  to  capture  advanced  product  data  (including  geometry,  features,  toler¬ 
ances,  and  other  attributes  in  computer-interpretable  form)  that  its  contractors  are 
generating  and  to  utilize  the  existing  capability  of  engineering  software.  Contrac¬ 
tors  create  these  data  not  only  during  initial  design  but  also  during  reprocurement, 
so  DoD  can  begin  collecting  them  on  virtually  any  competitive  item  it  buys. 

DoD  should  survey  its  suppliers  and  determine  what  product  data  formats  they 
support  and  should  do  the  same  with  its  internal  engineering  activities.  DoD 
should  upgrade  its  electronic  data  library  (the  Joint  Engineering  Data  Management 
Information  and  Control  System,)  to  accommodate  files  of  any  format  and  provide 
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users  with  the  capability  to  view  those  files.  DoD  should  form  a  cross-functional 
team  to  identify  and  resolve  technical  issues  (e.g.,  software  revision  control)  with 
accepting,  storing,  and  distributing  product  data  in  several  formats.  Most  impor¬ 
tant,  DoD  should  recognize  that  no  single  format  will  suit  all  of  its  needs,  and  that 
the  formats  it  uses  will  change  over  time  as  software  capabilities  evolve. 

One  approach  for  comprehensively  addressing  these  recommendations  would  be 
to  organize  an  Advanced  Technology  Concept  Demonstration  under  the  Defense 
Science  and  Technology  Program.  That  demonstration  could  be  managed  by  the 
Joint  Electronic  Commerce  Program  Office  with  participation  of  the  military 
services  and  the  Defense  Logistics  Agency. 
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Chapter  1 

Problem  Statement 


Department  of  Defense  (DoD),  through  its  Defense  Logistics  Agency  (DLA), 
manages  approximately  4  million  consumable  items  to  support  military  opera¬ 
tions.  The  military  services  manage  roughly  an  additional  1  million  reparable 
components  and  end  items.  Associated  with  these  5  million  items,  DoD  owns  ap¬ 
proximately  107  million  sheet  images  of  engineering  data.^  While  most  of  these 
data  were  originally  produced  by  private-sector  defense  manufacturers,  DoD  has 
acquired  the  data  to  competitively  procure  spare  parts,  to  maintain  defense  hard¬ 
ware  in  the  field  and  in  depots,  and  to  modernize  weapon  systems  when  a  private 
contractor  is  not  available. 

Historically,  these  data  have  been  recorded  on  paper  and  then  photographed  and 
attached  to  aperture  cards.  These  media  are  undesirable  because  they  can  be 
physically  difficult  to  access  and  reproduce,  they  are  subject  to  physical  damage, 
and  they  deteriorate  over  time.  Perhaps  most  significantly,  these  media  are  incom¬ 
patible  witfi  modem  mechanical  engineering  software  technologies. 

In  the  late  1980s,  DoD  embarked  on  an  effort  to  scan  virtually  all  its  product 
documents  into  electronic  format.  DoD  has  chosen  an  approach  that  converts  its 
product  data  into  electronic  “pictures”  called  raster  images.  This  approach  solves 
the  problems  of  physical  access  and  damage.  As  such,  it  preserves  the  data  repre¬ 
senting  the  way  products  were  originally  designed  and  made.  DoD’s  approach, 
however,  does  not  address  the  way  products  are  designed  and  made  today  and  the 
ways  in  which  they  will  be  made  in  the  future. 

Substantial  engineering  software  capabilities  exist  today,  and  they  are  evolving 
rapidly.  Those  capabilities  mean  that  product  definition  data  are  useful  to  many 
functions,  such  as  manufacturing  and  training.  Each  function  can  use  the  data  in 
electronic  form  to  visualize  the  product  and  to  perform  actions  on  the  product. 

DoD — from  military  engineers  to  high-level  managers — ^is  aware  of  the  capabili¬ 
ties  offered  by  engineering  software,  but  has  yet  to  define  a  structured  approach  to 
adopting  those  capabilities,  especially  with  respect  to  spare  parts  procurement.  In 
the  field,  at  defense  engineering  activities  and  repair  depots,  DoD  engineers  do 
have  a  panoply  of  advanced  engineering  software.  The  problem  lies  not  in  what 
engineering  software  DoD  employs,  but  in  what  format  or  formats  it  chooses  to 
issue  the  resulting  data  to  contractors  for  product  procurement. 


'  Joint  Engineering  Data  Management  Information  and  Control  System  (JEDMICS)  Home 
Page  on  the  World  Wide  Web  at  http://206.3.148.4/gsc/c4spec/C4SPEC03.HTM,  8  July  1998. 
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The  current  DoD  practice  is  to  convert  all  product  data,  whether  from  paper  or  the 
most  advanced  software  system,  into  the  lowest  electronic  common  denomina¬ 
tor — ^raster  format.  This  practice  means  that  contractors  taking  advantage  of  com¬ 
puter-aided  engineering  and  manufacturing  systems  must  take  DoD’s  raster  data 
and  recreate  the  data  in  more  advanced  formats.  While  DoD  is  nominally  paying 
for  the  manufacture  of  parts,  it  is  in  reality  paying  for  data  format  conversion,  en¬ 
gineering  validation,  and  manufacturing.  DoD  takes  delivery  of  the  resulting  parts 
but  does  not  take  delivery  of  the  “intelligent”  data  that  helped  to  produce  those 
parts.  If,  for  competitive  items,  DoD  makes  future  awards  to  different  contractors, 
it  pays  for  the  data  reengineering  again  and  again. 

DoD  does  recognize  the  advantages  of  more  advanced  formats,  generally  referred 
to  as  vector  formats.  For  the  time  being,  however,  DoD  is  awaiting  the  completion 
and  industry  adoption  of  a  series  of  international  standards  known  collectively  as 
ISO  10303,  Industrial  Automation  Systems  and  Integration — Product  Data  Repre¬ 
sentation  and  Exchange  (STEP).  While  other  vector  formats  (some  proprietary 
and  some  open)  are  readily  available  today,  DoD  is  taking  a  wait-and-see  position, 
hoping  for  the  complete  development  and  acceptance  of  STEP. 


Issues 


The  thoughts  presented  in  this  paper  began  when  DLA  asked  the  Logistics  Man¬ 
agement  Institute  (LMI)  to  investigate  the  economics  associated  with  preparing 
STEP-formatted  files.  As  background  to  that  investigation,  we  formulated  the 
following  questions: 

♦  What  is  the  status  of  STEP? 

♦  What  are  the  capabilities  of  STEP  relative  to  commercially  available  me¬ 
chanical  engineering  software  products? 

♦  What  alternatives  to  STEP,  if  any,  exist? 

In  the  remainder  of  this  paper,  we  examine  the  state-of-the-art  in  commercially 
available  design  and  manufacturing  software  (with  some  examination  of  engi¬ 
neering  analysis  capability  also).  In  parallel,  we  examine  the  capability  of  STEP 
and  another  leading  standard  to  incorporate  the  software  products’  data.  We  then 
develop  five  product  data  format  strategies  that  DoD  could  adopt:  the  present 
strategy  plus  four  alternatives  that  would  capture  and  utilize  data  in  advanced 
software  formats.  We  emphasize  that  the  alternatives  are  not  mutually  exclusive; 
each  approach  might  be  appropriate  for  a  different  set  of  circumstances  and,  thus, 
DoD  could  adopt  all  simultaneously.  We  end  the  paper  with  our  findings,  conclu¬ 
sions,  and  recommendations  for  developing  the  strategies  more  fully  and  imple¬ 
menting  them. 
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Problem  Statement 


Scope 


We  focus  on  strategies  and  software  supporting  the  design  and  manufacture  of 
mechanical  and  structural  items,  such  as  aircraft,  automotive,  and  ship  compo¬ 
nents.  While  strategies  for  electronics  and  other  commodities  are  also  important, 
we  focus  on  mechanical  items  for  several  reasons.  First,  mechanical  and  structural 
items  are  omnipresent.  Second,  their  engineering  represents  a  significant  cost  to 
DoD.  Approximately  13  percent  of  defense  industry  engineers  are  mechanical  en¬ 
gineers,  and  another  12  percent  are  aeronautical  engineers.^  Finally,  the  interna¬ 
tional  standards  supporting  the  interchange  of  mechanical  product  data  are  more 
fuUy  developed  than  those  for  other  commodities.  If  a  standard-based  strategy 
(such  as  STEP)  is  to  be  adopted  by  DoD,  it  should  be  first  adopted  for  a  commod¬ 
ity  where  the  standard  is  mature. 


^  Logistics  Management  Institute,  The  Defense  Manufacturing  Base:  Activity-Based  Cost 
Profiles  and  Their  Implications  for  Funding  Manufacturing  Technology,  Report  NT301R1,  Eric 
L.  Gentsch,  et  al.,  January  1994,  p.  D-4. 
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Chapter  2 

Engineering  Software  Capability  Survey 


Before  outlining  alternative  product  data  strategies  available  to  the  DoD,  we 
sought  to  identify  the  major  mechanical  engineering  software  products  and  their 
capabilities.  We  focused  on  software  for  computer-aided  design  (CAD)  and  com¬ 
puter-aided  manufacturing  (CAM).  Because  the  industry  is  evolving  so  rapidly,  it 
is  important  to  consider  not  only  DoD’s  current  requirements,  but  also  what  capa¬ 
bilities  off-the-shelf  products  offer  and  what  capabilities  are  emerging.  With  a 
view  of  what  commercial  software  capabilities  are,  and  are  likely  to  be,  DoD  can 
make  more  informed  decisions  in  establishing  its  requirements  for  procuring 
software  and  for  maintaining  product  data. 

In  this  section,  we  first  present  the  CAD  products  with  the  largest  market  share. 
We  then  provide  a  capabilities  comparison  for  some  of  the  major  CAD  products 
and  some  of  the  major  CAM  products. 

The  overall  CAD  market  is  estimated  at  $4.7  billion,  having  grown  17.2  percent  in 
1997  and  18.5  percent  in  1996.  Table  2-1  lists  the  CAD  market  leaders,  as  defined 
by  1997  sales.  Note  that  some  consolidation  is  taking  place,  as  Parametric  Tech¬ 
nology  Corporation  has  acquired  Computervision  to  complement  its  Pro/Engineer 
line,  and  Dassault  Systemes  now  owns  SolidWorks  in  addition  to  its  long¬ 
standing  CATIA  product. 

In  the  following  sequence  of  tables,  we  present  the  results  of  a  market  research 
study  aimed  at  comparing  the  capabilities  of  some  major  CAD/CAM  products. 

We  included  some  major  CAM  products  because  of  the  increasing  integration  of 
CAD  and  CAM  capabilities  and  because  of  a  possible  strategy,  discussed  later  in 
this  paper,  whereby  DoD  could  receive,  store,  and  distribute  manufacturing  proc¬ 
ess  data.  The  software  capabilities  that  we  list  are  based  on  vendor’s  published 
specifications;  other  than  prior  personal  experience  by  the  authors  with  some  of 
the  products,  we  made  no  attempt  to  validate  the  functionality  cljiimed  by  the 
vendors. 
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Table  2-1.  The  1997  CAD  Market  Leaders 


Product  names 

Company 

1997  market 
(millions) 

Pro/Engineer 

Parametric  Technology  Corporation 

$850 

CATIA 

Dassault  Systemes  (marketed  by  IBM) 

$802 

l-DEAS 

SDRC 

$320 

SolidWorks 

Dassault  Systemes 

$280 

Computenrision 

Parametric  Technology  Corporation 

$240 

AutoCAD 

Autodesk 

$230 

Unigraphics  and 
SolidEdge 

Unigraphics  Solutions  (EDS) 

$220 

MICROCADAM 

CADAM  Systems  Company 

$200 

MSC/Patran, 
MSC/Nastran,  and 
SuperForge 

MacNeal-Schwendler  Corporation 

$170 

SolidDesigner 

CoCreate  (Hewlett  Packard) 

$160 

EUCLID,  STRIM,  and 
Prelude 

Matra  Datavision 

$155 

MicroStation,  EMS, 
and  SolidEdge 

Intergraph 

$110 

Note:  SolidEdge  is  a  joint  venture  between  Unigraphics  Solutions  and  Integraph. 
Source:  “CAD/CAM  Sales  Skyrocket,”  Computer-Aided  Engineering,  January  1 998,  p. 
14. 


Table  2-2  lists  the  CAD/CAM  products  whose  capabilities  we  surveyed.  We  in¬ 
clude  two  neutral  file  formats:  ANSI/US  PRO/IPO  100-1996,  Initial  Graphics 
Exchange  Specification  IGES  5.3  (IGES),  and  the  ISO  10303  series  titled  Indus¬ 
trial  Automation  Systems  and  Integration — Product  Data  Representation  and  Ex¬ 
change  (STEP).  As  neutral  formats,  they  offer  the  potential  to  translate  data  from 
any  system  to  any  other  system;  we  wanted  to  see  what  systems  indeed  support 
those  formats.  Also,  the  translation  of  data  involves  both  quantity  (translating  all 
available  data  types)  and  quality  (translating  each  data  type  correctly).  We  wanted 
to  see  what  features  or  capabilities  offered  by  the  CAD/CAM  products  that  the 
neutral  formats  could  handle.  Any  data  type  not  handled  by  the  neutral  formats 
will  be  lost  in  translation. 
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Table  2-2.  Overall  Capabilities  of  Major  CAD/CAM  Systems 


System 

Company 

Operating  system 

Capability 

AutoCAD  Mechani¬ 
cal  Desktop  2.0 

AutoDesk 

www.autodesk.com 

Windows  95 
Windows  NT 

CAD 

CATIA 

Dassualt  Systemes/IBM 
www.catia.com 

AIX 

UNIX 

CAD/CAM/CAE 

l-DEAS  Master 
Series  6 

SDRC 

www.sdrc.com 

Unix 

Windows  NT 

CAD/CAE 

Pro/Engineer 

Parametric  Technology  Corpo¬ 
ration 

www.ptc.com 

Unix 

Windows  NT 

CAD/CAM/CAE 

SURFCAM  7.0 

Surfware 

www.surfware.com 

Windows  95 
Windows  NT 

CAM 

Unigraphics 

EDS 

www.unigraphics.com 

Unix 

Windows  NT 

CAD/CAM/CAE 

IGES 

None — industry  standard 

Not  applicable 

File  format  only 

STEP 

None — industry  standard 

Not  applicable 

File  format  only 

Note:  CAE  =  computer-aided  engineering. 


In  Table  2-3,  we  display  the  basic  modeling  capabilities  of  the  products.  Modeling 
refers  to  the  software’s  capability  to  generate  geometry. 

Table  2-4  shows  some  general  modeling  features  of  the  products.  The  modeling 
engine  refers  to  the  underlying  software  that  generates  and  represents  the  geome¬ 
try  of  the  product.  Different  software  products  using  the  same  modeling  engine 
can  generally  read  and  manipulate  product  geometry  without  data  loss.  In  some 
respects,  third-party  modehng  engines,  such  as  ACIS  and  Parasolid,  can  be 
viewed  as  de  facto  standards  that  will  compete  with  the  formal  standards  IGES 
and  STEP  for  market  acceptance. 

Neither  the  IGES  nor  the  STEP  standards  support  parametric  design  and 
“tolerancing.”  Tolerancing  is  the  ability  to  specify  manufacturing  limits  about 
nominal  design  dimensions.  Parametric  design  and  the  ability  to  include  design 
constraints  are  widely  available  capabilities  that  the  standards  bodies  have  been 
slow  to  adopt.  Tolerencing  is  anticipated  to  emerge  in  STEP’S  AP  224,  but  it  is 
not  yet  supported  by  the  software  industry.  Note  also  that  the  modeling  engines 
ACIS  and  Parasolid  do  not  support  these  features  either;  where  offered  (e.g.,  in 
AutoCAD),  parametrics  and  tolerancing  data  are  “extra”  to  the  data  stored  by  the 
modeling  engine. 
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Table  2-3.  Modeling  Capabilities  of  Major  CAD/CAM  Products 


System 

2-D  Vector 

3-D  Surface 

3-D  Solid 

AutoCAD 
Mechanical 
Desktop  2.0 

Yes 

Yes:  NURBS  and 
splines 

Yes:  CSG  and  feature- 
based 

CATIA 

Yes:  includes  2-D/3-D 
integration 

Yes:  polynomials, 
splines,  Bezier,  and- 
NURBS 

Yes:  CSG 

l-DEAS  Master 
Series  6 

Yes 

Yes:  NURBS,  Bezier, 
lofted  surfaces,  ruled 
surfaces,  and  sur¬ 
faces  of  revolution 

Yes 

Pro/Engineer 

Yes 

Yes:  NURBS,  Bezier, 
and  polylines 

Yes:  CSG 

SmartCAM 

Yes 

Yes:  NURBS  and 
polylines 

Yes:  CSG 

SURFCAM  7.0 

Yes 

Yes:  NURBS,  Bezier, 
and  polynomials 

Yes:  B-Rep  (uses 
SolidWorks  Modeler) 

Unigraphics 

Yes 

Yes:  Lofted  surfaces 
and  surfaces  of  revo¬ 
lution 

Yes:  CSG 

IGES 

Yes 

Yes:  NURBS,  splines, 
Bezier,  and  polynomi¬ 
als 

No 

STEP 

Yes:  AP201  (but  no 
industry  translators 
available) 

Yes:  AP203 

Future:  AP214 
(manifold  surfaces) 

Yes:  AP203  (B-Rep) 

Future:  AP214  (B-Rep, 
CSG,  others)  and 
AP224 

Notes:  AP  =  application  protocol;  CSG  =  constructive  solid  geometry;  NURBS  =  non-uniform 
rational  b-splines;  B-Rep  =  boundary  representation. 


Constructive  solid  geometry  represents  solid  objects  as  unions,  intersections,  or  differences  of 
other  solid  objects. 
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Table  2-4.  Modeling  Features  of  Major  CAD/CAM  Products 


System 

Modeling  engine 

Parametric 

Tolerancing 

AutoCAD 
Mechanical 
Desktop  2.0 

ACIS  3.0 

Yes 

Yes 

CATIA 

Proprietary 

Yes 

Yes 

l-DEAS  Master 
Series  6 

Proprietary 

Variational  with 
graphical  display  of 
constraints 

Yes 

Pro/Engineer 

Proprietary 

Yes 

Yes 

SmartCAM 

ACIS  2.1  and  Proprie¬ 
tary 

No 

Yes:  dimensioning  and 
notes 

SURFCAM  7.0 

Parasolid  and  Proprie¬ 
tary 

Yes 

Yes:  tolerant  modeling 

Unigraphics 

Parasolid 

Variational  with  con¬ 
straints 

Yes 

iGES 

Not  applicable 

No 

No 

STEP 

Not  applicable 

No 

Future:  AP214,  AP224 

Notes:  The  ACIS  modeling  engine  is  a  product  of  Spatial  Technology  Corporation.  The  Para- 
solid  modeling  engine  is  a  product  of  Unigraphics  Solutions  (an  EDS  company). 


Table  2-5  shows  the  design,  engineering  analyses,  and  product  data  management 
tools  that  are  supported  by  the  CAD/CAM  products.  “Design  tools”  refers  to  ca¬ 
pabilities  specific  to  various  commodities,  such  as  sheet  metal  and  molding.  Engi¬ 
neering  analyses  refers  to  capabUities  for  performing  static,  dynamic,  thermal,  or 
other  evaluations  of  a  design.  Product  data  management  is  the  process  of  storing 
and  accessing  data  supporting  the  design,  such  as  bills  of  materials  and  configura¬ 
tion  management. 
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Table  2-5.  Design,  Analysis,  and  Data  Management  Capabilities  of  Major 

CAD/CAM  Products 


System 

Design  tools 

Engineering  analyses 
tools 

Product  data 
management 

AutoCAD 
Mechanical 
Desktop  2.0 

Yes:  through  third-party 
software 

Yes:  part  properties 
and  other  capabilities 
through  third-party 
software 

Yes:  through  third-party 
software 

CATIA 

Yes:  sheet  metal,  com¬ 
posites,  molds,  and 
dies 

Yes:  part  properties, 
kinetic  analysis  of  as¬ 
semblies,  and  finite 
element  analysis 

Yes:  bill  of  materials 
and  revision  control, 
access  control, 
searchable  database, 
and  part  library 

l-DEAS  Master 
Series  6 

Yes:  molds  and  dies, 
hulls,  injection  molding, 
sheet  metal,  wiring  har¬ 
nesses,  and  material 
data  catalogs 

Yes:  part  properties; 
part  comparison;  non¬ 
linear  finite  element 
analysis  (acoustic, 
modal,  structural,  fa¬ 
tigue);  and  dynamic 
analysis 

Yes:  manages  all  part, 
assembly,  drawing, 
engineering  analysis, 
test,  and  machine  data 
within  team  project  en¬ 
vironments 

Pro/Engineer 

Yes:  optimization 

Yes:  part  properties, 
stress,  thermal,  stiff¬ 
ness,  vibration,  and 
impact 

Yes:  integrates  part 
data  with  manufactur¬ 
ing,  marketing,  and 
management  data; 
controlled  access;  and 
relational  database  for 
searching 

SmartCAM 

No 

No 

No 

SURFCAM  7.0 

Yes:  molds  and  dies 
and  plastic  parts 

No 

No 

Unigraphics 

Yes:  injection  molding, 
sheet  metal,  connection 
to  ICAD*  for  knowledge- 
based  engineering, 
wiring  harnesses,  and 
routing 

Yes:  injection  molding 
and  finite  element 
analysis 

Yes:  bill  of  materials 
management,  part  re¬ 
vision,  manages  design 
team  access,  relational 
database  can  allow 
search  on  product  at¬ 
tributes 

IGES 

Not  applicable 

Not  applicable 

No 

STEP 

Not  applicable 

Not  applicable 

Future:  Some  capability 
to  store  product  data  in 
AP224;  AP232 

*ICAD  is  sold  by  Knowledge  Technologies  International  under  license  from  Concentra. 


Table  2-6  lists  the  manufacturing  assembly  tools  offered  by  the  CAD/CAM  prod¬ 
ucts.  Manufacturing  tools  support  the  creation  of  process  plans,  such  as  routings, 
tool  and  fixture  lists,  and  machine  instructions.  Assembly  tool  capabilities  include 
checking  for  clearance  and  tolerance  overlap. 
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Table  2-6.  Manufacturing  and  Assembly  Tools  Offered  by  Major 
CAD/CAM  Products 


System 

Manufacturing  tools 

Assembly  tools 

AutoCAD 
Mechanical 
Desktop  2.0 

Yes;  through  third-party  software 

Yes 

CATIA 

Yes:  process  planning;  NC  programming 
(2-  to  5-axis  milling  and  turning);  tool  li¬ 
braries;  NC  code  analysis;  tool  path  verifi¬ 
cation;  sterolithography;  and  robotic 
programming 

Yes;  automatic  functional 
dimensioning  and  toler- 
anacing 

I-DEAS  Master 
Series  6 

Yes:  integrated  with  CAMAX  and  Smart¬ 
CAM,  SDRC’s  NC  programming  systems 

Yes;  standard  parts  catalog 

Pro/Engineer 

Yes:  material  libraries;  tool  libraries;  fixture 
libraries;  cutting  database;  NC  program¬ 
ming  (2.5-to  5-axis  milling,  2-  to  4-axis 
turning,  2-axis  electro  discharge  machin¬ 
ing) 

Yes;  kinematic  analysis 
including  cams,  slots,  and 
gears 

SmartCAM 

Yes:  material  libraries,  tool  libraries;  NC 
programming  (2.5-  to  5-axis  milling,  2-to  6- 
axis  turning,  2-  to  5-axis  electro  discharge 
machining,  punch  and  waterjet);  tool  path 
verification;  part  nesting;  and  tool  path  op¬ 
timization 

No 

SURFCAM  7.0 

Yes:  tool  libraries,  fixture  libraries,  2-to  5- 
axis  NC  milling  and  turning,  and  tool  path 
verification  through  integration  of  third- 
party  software  (SIRIUS) 

No 

Unigraphics 

Yes:  NC  programming  (2-  to  5-axis  milling, 
2-axis  turning,  2-to  5-axis  electro-discharge 
machining,  tool  path  verification  through 
third-party  software,  tool  inventory  man¬ 
agement,  machining  database,  sheet  metal 
fabrication,  and  sheet  metal  nesting 

Yes:  standard  parts  cata¬ 
log,  kinematic  with  library  of 
machine  elements,  and 
component  clearance 
analysis 

IGES 

Not  applicable 

Not  applicable 

STEP 

Not  applicable 

Not  applicable 

As  shown  in  Table  2-7,  all  of  the  products  we  examined  support  the  IGES  inter¬ 
change  standard.  Most  support  the  STEP  AP203,  which  translates  nominal  ge¬ 
ometry.  None  of  the  products  support  STEP’S  two-dimensional  standard,  or  the 
anticipated  AP224  that  includes  manufacturing  data.  Increasingly,  CAD  vendors 
are  offering  direct  translators  (e.g.,  I-DEAS  to  AutoCAD)  that  are  tuned  to  the 
specific  packages.  In  addition  to  these  exchange  formats,  which  enable  the  data  to 
be  edited,  almost  all  CAD  vendors  now  offer  software  that  enables  files  in  their 
native  format  to  be  viewed  (including  pan,  zoom,  and  rotation),  but  not  edited. 
Much  of  this  software  can  be  downloaded  from  the  Internet  for  free  or  for  a  nomi¬ 
nal  charge. 
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Table  2-7.  Data  Exchange  Formats  Offered  by  Major  CAD/CAM  Products 


System 

Data  exchange  formats 

AutoCAD 
Mechanical 
Desktop  2.0 

IGES  Version  5.3,  STEP  AP203,  DWF,  DWG,  DXF,  IDF,  SAT  (ACIS), 
STL,  VRML,  and  3DS  (3-D  Studio) 

CATIA 

IGES  Version  5.2,  STEP  AP203  and  214,  CATIA-CADAM,  CATIA- 
ALIAS,  CALS,  DXF,  DWF,  and  Hybrid  Raster 

l-DEAS  Master 
Series  6 

IGES  5.3  with  tuned  translators  for  major  CAD  systems,  STEP  AP203 
and  214,  ABACUS  (to/from),  ANSYS  (to/from),  AutoCAD  (to/from), 
CADAM  (to/from),  CADDS  5  (to/from),  CAMAND  (to),  CATIA  (to/from), 
JAMA-IS,  NASTRAN  (to/from),  Pro/Engineer  (to),  SmartCAM  (to),  and 
Unigraphics  (to/from) 

Pro/Engineer 

IGES,  STEP  AP203  and  214,  CADAM,  CADDS  5,  CATIA,  l-DEAS, 

PDGE  (Ford),  and  STL 

SmartCAM 

IGES,  SAT  (ACIS),  DXF,  and  DWG 

SURFCAM  7.0 

IGES  with  tuned  translators  for  major  CAD  systems,  CADL,  SAT 
(ACIS),  and  DXF 

Unigraphics 

IGES,  STEP  AP203  and  214,  CATIA  (to/from),  DXF,  JAMA-IS,  STL, 
and  XT 

IGES 

Not  applicable  (IGES  is  a  data  exchange  format) 

STEP 

Not  applicable  (STEP  is  a  data  exchange  format) 
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Chapter  3 

Product  Data  Alternatives 


In  this  chapter,  we  discuss  five  major  product  data  alternatives  available  to  DoD. 
We  label  each  alternative  based  on  the  underlying  format  in  which  the  product 
data  would  be  stored  and  distributed:  two-dimensional  raster  format;  two- 
dimensional  vector  format;  three-dimensional,  proprietary,  vector  format;  three- 
dimensional,  neutral,  vector  format;  and  three-dimensional,  neutral,  machine  in¬ 
structions.  For  each  alternative,  we  discuss  the  operational  scenario,  economic 
issues,  and  technical  issues.  We  also  summarize  JEDMICS  under  the  first  alterna¬ 
tive  because  almost  all  of  the  files  in  that  system  are  in  raster  format. 

Two-Dimensional  Raster  Format 

Product  data  in  two-dimensional  raster  format  are  a  picture  of  a  traditional  blue¬ 
print  or  aperture  card  image.  Also  called  bitmaps,  these  data  only  can  be  edited  by 
manipulating  individual  pixels  in  the  image.  They  contain  none  of  the  object- 
oriented  “intelligence,”  such  as  lines,  surfaces,  or  holes,  that  make  up  more  ad¬ 
vanced  data  formats. 

Operational  Scenario 

Under  this  alternative  (which  is,  in  fact,  the  standard  approach  today),  DoD  ac¬ 
quires  product  data  from  the  initial  designer  and  from  those  data  (regardless  of 
format)  generates  and  archives  a  two-dimensional  raster  image.  When  the  need  to 
procure  arises,  the  DoD  buying  agency  would  retrieve  and  distribute  the  image 
either  as  an  electronic  or  printed  “request  for  quotation.” 

To  generate  a  quote,  the  contractor  would  perform  the  following  tasks: 

♦  Generate  a  bill  of  materials. 

♦  Generate  a  routing  for  manufacturing  operations. 

♦  Identify  tools  and  fixtures. 

♦  From  the  raster  image,  generate  computer-based  geometry  (e.g.,  a  vector 
model)  using  CAD  software. 


3-1 


♦  Using  CAD  manufacturing  software,  create  a  cutting  tool  path(s)  from  the 
computer  model  to  determine  machining  time. 

♦  Develop  the  quotation.^ 

Some  contractors  may  develop  quotations  using  parametric  equations  or  rules  of 
thumb,  in  which  case,  some  of  the  tasks  outlined  above  would  unfold  after  an 
award  is  granted.  Also,  some  or  all  of  the  tasks  above  might  not  be  necessary  if 
the  contractor  had  built  the  part  before  and  had  saved  the  information  from  the 
earlier  contract,  or  if  a  person  could  interpret  the  raster  picture  and  use  machine 
tools  directly  to  make  the  part.  Using  raster-to-vector  software  can  assist  in  creat¬ 
ing  vector  models  from  raster  images.^  Following  award  of  a  contract  or  delivery 
order,  the  contractor  would 

♦  order  raw  materials  and  components,  if  necessary; 

♦  acquire  or  design  and  build  tooling  and  fixtures; 

♦  complete  process  planning,  including  specification  of  tooling,  fixturing, 
and  tool  paths; 

♦  generate  a  numerical  control  code  (machine  tool  instructions); 

♦  postprocess  a  numerical  control  code; 

♦  generate  a  shop  floor  information  package,  including  routing  information, 
tooling  sheet(s),  setup  fixture  sheet(s),  and  directions  for  accessing  the 
control  code  for  each  machine; 

♦  schedule  the  job;  and 

♦  make  the  parts. 


JEDMICS 


Today,  DoD  stores  product  data  on  paper,  on  aperture  cards,  and  in  JEDMICS. 
JEDMICS  electronically  stores  product  information  previously  recorded  on  paper 
and  aperture  cards.  JEDMICS  takes  engineering  drawings  and  related  text  that 


'The  quotation  for  a  batch  of  machined  parts  is  usually  based  on  a  variation  of  the  following 
formula:  (material  cost  +  material  markup)  +  (setup  rate  x  setup  time)  +  {machine  rate  x  (load  time 
+  cycle  time  +  unload  time)  x  number  of  parts}.  The  material  markup  covers  piuchasing  and  han¬ 
dling  costs;  the  setup  and  machining  rates  include  factors  for  overhead  and  profit.  The  first  time  a 
part  is  quoted,  nonrecurring  expenses  may  be  added  for  special  tooling,  fixtures,  and  engineering 
time.  Current  machine  and  setup  rates  for  precision  machine  shops  are  $50  to  $60  per  hour. 

^  DoD  is  conducting  a  research  program,  called  the  Automated  Document  Conversion  System, 
to  explore  the  utility  of  raster-to-vector  conversion  software  and  service  bureaus  and  to  fund  the 
creation  of  two-dimensional  vector  data. 
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have  been  scanned  and  stores  them  on  wide-area,  network-accessible  optical  me- 

•  •  *3 

dia,  providing  near-immediate  online  access  at  distributed  workstations. 

The  JEDMICS  program  office  states  that  its  system  is  the  largest  electronic 
document  management  system  in  the  world,  and  it  is  growing  as  more  documents 
are  converted  from  paper  and  aperture  cards.  Table  3-1  shows  the  number  of  files 
in  JEDMICS  in  March  1997.  The  total  of  approximately  40  million  includes  du¬ 
plicates  of  the  same  image  that  are  stored  at  separate  JEDMICS  locations.  By  No¬ 
vember  1997  (the  latest  figure  available),  the  system  had  grown  to  over  64  million 
files. 

Table  3-1.  Number  of  JEDMICS  Files  by 
Defense  Component,  as  of  1  March  1997 


Defense  component 

Number  of 
JEDMICS  files 

Navy 

25,537,391 

Defense  Logistics  Agency 

5,942,766 

Army 

4,280,099 

Air  Force 

3,434,117 

Total 

39,194,373 

Source;  World  Wide  Web  site  at  http://206.3.148.4/ 
gsc/c4spec/c4spec07.htm,  11  June  1998. 


While  JEDMICS  is  nominally  a  library  system,  independent  of  the  format  of  the 
data  files  stored  within,  JEDMICS  is,  in  practice,  synonymous  with  the  two- 
dimensional  raster-format  images  stored  in  it.  Today,  virtually  all  JEDMICS  files 
are  in  this  format,  known  as  “C4.”  DoD  defines  the  format  requirements  for  C4  in 
military  specification  MIL-PRF-28002C,  Raster  Graphics  Representation  in  Bi¬ 
nary  Format,  Requirements  for.  The  C4  format  is  a  tiled,  binary  bitmap  with  a 
resolution  of  200  pixels  per  inch.  Using  this  format,  JEDMICS  can  store  images 
of  engineering  drawing  sheets  from  ANSI  A  size  (11  inches  wide  by  8.5  inches 
high)  to  ISO  AO  X  3  size  (2,523  millimeters  wide  by  1,189  millimeters  high). 

JEDMICS  is  a  large  advance  over  both  paper  and  aperture  cards  for  several  rea¬ 
sons.  First,  it  physically  preserves  the  product  information  from  deterioration.'^ 
Second,  it  enhances  the  retrieval  and  distribution  of  the  data  by  enabling  images  to 
be  transferred  from  a  central  library  to  remote  users  over  a  computer  network.  Fi¬ 
nally,  it  replaces  individual  military  service  library  systems  and  thereby  offers  a 
standard  DoD  format  and  interface. 


^  Information  in  this  section  drawn  from  the  JEDMICS’  program  World  Wide  Web  site  at 
http;//206.3.I48.4/jedmics.html,  II  June  1998. 

*  Electronic  storage  eliminates  deterioration  due  to  handling.  Optical  disks  do  have  limited 
lifespans,  and  data  stored  on  them  may  need  to  be  re-recorded  every  10  years  or  so. 
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Despite  these  advantages,  the  JEDMICS  C4  format  has  several  drawbacks.  Two 
are  technical;  one  is  philosophical.  The  200  pixel  per  inch  specification  produces 
drawings  of  fair  quality;  some  drawings  need  a  higher  degree  of  resolution.^  Also, 
C4  data  are  “digital”  in  that  they  are  stored  on  opto-electronic  media  and  are 
viewed  on  computers,  but  tiiey  are  “unintelligent”  in  that  they  are  raster  images 
(pictures).  As  such,  they  must  be  reentered  into  CAD  systems  if  the  product  data 
are  to  be  used  in  automated  manufacturing. 

This  technical  drawback  leads  to  a  philosophical  drawback.  Although  JEDMICS 
nominally  can  accept  files  in  any  format,  the  JEDMICS  operational  philosophy 
seems  to  be  to  convert  CAD  files,  and  not  just  paper  and  aperture  cards,  into  C4 
format.  For  example,  the  JEDMICs  program  office,  on  its  Web  site,  cites  the  need 
for  software  converters  to  translate  drawings  produced  by  CAD  programs  into  C4 
format.  While  a  neutral  format  for  viewing  product  data  is  desirable,  by  actually 
converting  the  data  to  C4,  DoD  is  losing  “intelligence”  that  the  CAD  systems  em¬ 
bed  in  their  files.  Note  that  this  drawback  applies  to  data  that  DoD  acquires  for 
new  products  and  also  to  data  created  by  manufacmrers  when  DoD  reacquires  ex¬ 
isting  products. 

Economic  Issues 

While  no  more  information  exists  in  a  raster  product  data  file  than  a  blueprint, 
raster  files  do  have  the  capability  of  being  electronically  distributed  (e.g.,  over  the 
Internet),  reducing  distribution  time  and  cost.^  No  change  is  likely  in  manufactur¬ 
ers’  prices  because  they  must  perform  the  tasks  with  raster  images  as  if  they  had 
received  paper  (a  minor  exception  being  the  time  saved  if  raster-to- vector  conver¬ 
sion  software  is  used).  DoD  might  see  lower  data  maintenance  costs  due  to  re¬ 
duced  storage  space  requirements  and  due  to  the  better  accounting  of  costs  that 
comes  with  concentrating  a  large  amount  of  information  in  a  relatively  few  loca¬ 
tions. 

Technical  Issues 

Two-dimensional  raster  images  produce  technical  benefits  for  DoD  in  facilitating 
document  storage  and  distribution.  They  produce  few  benefits  for  manufacturers, 
who  will  probably  need  to  print  paper  copies  for  their  machinists  and  may  need  to 
produce  vector-based  files  for  their  computer-based  machine  controls. 

Raster  images  must  be  readable  to  be  useful.  The  pixel  resolution  must  be  high 
enough  to  preserve  the  legibility  of  handwriting.  Smudges,  tears,  or  other  defects 


’  The  JEDMICS  program  office  states  that  “the  defense  community  needs  image  resolutions 
up  to  1,200  pixels  per  inch.”  See  the  World  Wide  Web  site  at  http://206.3.148.4/gsc/ 
c4spec/C4SPEC03.HTM. 

*  Blueprints  can  be  transmitted  electronically  by  facsimile,  but  the  utility  of  this  generally  is 
limited  by  paper  size  restrictions. 
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in  the  original  document  will  be  perpetuated  after  scanning  into  electronic  format. 
Cosmetic  defects,  if  not  corrected,  will  lead  to  time  delays  during  later  procure¬ 
ments  as  the  buyer  and  manufacturer  will  need  to  resolve  the  drawing  defects. 
Cosmetic  defects  can  translate  to  product  defects  if  they  are  not  apparent  to  a 
manufacturer.  For  example,  a  smudge  that  obliterates  a  key  tolerance  might  not  be 
noticed  as  a  drawing  defect  by  the  manufacturer. 

Two-Dimensional  Vector  Format 

Two-dimensional  vector  format  data  resemble  conventional  blueprints  when 
viewed  and  printed,  but  they  contain  more  information  and  are  more  easily  edited. 
Rather  than  being  a  collection  of  dots,  a  line,  for  example,  is  represented  as  an 
object  connecting  two  points  or  as  an  object  with  a  beginning  point,  direction,  and 
magnitude  (i.e.,  a  vector).  Objects,  such  as  lines,  may  be  copied,  moved,  changed, 
or  deleted  as  complete  entities.  Objects  may  be  grouped  to  represent  higher  order 
objects.  Objects  also  can  have  associated  properties  that  are  stored  in  an  object 
database.  Most  CAD  packages  include  standard  properties,  such  as  associative 
dimensions  and  tolerances.  Some  CAD  packages  allow  custom  properties,  where 
the  designer  can  specify  fields  such  as  material,  price,  and  color. 

Many  two-dimensional  vector  format  CAD  packages  offer  drawing  layers  that 
simplify  drafting  and  viewing.  For  example,  a  basic  drawing  could  be  placed  in 
one  layer,  and  dimensions  and  call-outs  placed  in  another  layer. 

Operational  Scenario 

The  operational  scenario  for  using  two-dimensional  vector  format  data  is  similar 
to  that  of  two-dimensional  raster  data.  Rather  than  acquiring  or  creating  a  raster 
image,  DoD  would  acquire  and  store  the  product  data  in  vector  format.  If  DoD 
standardized  on  a  format,  the  original  file  might  need  to  be  converted  to  that  stan¬ 
dard  format  (and  verified  for  accuracy). 

Contractors  would  use  almost  the  same  steps  as  with  raster  data  to  develop  quota¬ 
tions,  perform  manufacturing  engineering,  and  produce.  Rather  than  creating 
computer  models  from  scratch,  however,  contractors  may  be  able  to  use  the  vector 
file  as  input,  reducing  some  of  the  labor  required  for  model  generation. 

Economic  Issues 

Contrasting  with  two-dimensional  raster  files,  the  two-dimensional  vector  format 
offers  the  opportunity  for  the  vendor  to  use  more  (and  re-enter  less)  of  the  gov¬ 
ernment’s  technical  data.  This,  in  turn,  could  reduce  prices,  shorten  lead-times, 
and  improve  quality. 
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Depending  on  the  vector  format  chosen,  manufacturers  will  incur  expenses  in 
maintaining  vector-format  software  capability.  In  many  cases,  however,  this  capa¬ 
bility  is  a  nominal  expense  for  two-dimensional  formats  and  may  be  incurred  al¬ 
ready  as  a  cost  of  business  (i.e.,  is  not  incremental  to  DoD  business). 

Storing  and  maintaining  data  in  vector  format  may  require  DoD  to  purchase  soft¬ 
ware  and  labor  to  convert  files  into  a  standard  format  or  from  old  software  ver¬ 
sions  to  new  versions.  Validating  the  vector-format  file  may  introduce  liability 
issues  if  DoD  pays  a  contractor  to  do  the  work. 

Technical  Issues 

The  main  technical  benefits  of  two-dimensional  vector  data  are  that  they  are  edit¬ 
able  and,  at  least  in  terms  of  format,  unambiguous.  When  manufacturers  use  a 
customer-supplied  data  format,  fewer  errors  are  introduced  in  data  transcription. 

If  DoD  chooses  this  strategy,  it  will  need  to  decide  which  specific  format  or  for¬ 
mats  it  will  accept  and  how  it  will  store  and  maintain  them.  DoD  could  accept  all 
formats  and  store  them  in  the  order  received.  Or,  it  could  accept  all  formats  and 
convert  them  to  a  DoD  standard  format.  Alternatively,  it  could  require  delivery  of 
product  data  in  a  standard  format.  As  software  evolves,  DoD  also  wiU  require  a 
strategy  for  updating  files  to  the  current  software  revision  or  for  maintaining  the 
capability  to  read  old  formats. 

The  wide  variety  of  CAD  and  manufacturing  software  with  proprietary  modeling 
engines  may  make  a  neutral  file  format  desirable  to  facilitate  distribution  from  a 
customer  to  a  large  base  of  potential  suppliers.  Several  de  facto  interchange  stan¬ 
dards  are  available  for  two-dimensional  raster  data,  such  as  the  DXF  standard  de¬ 
veloped  by  AutoDesk,  Inc.  In  addition,  increasing  acceptance  of  modeling  kernels, 
such  as  those  developed  by  Spatial  Technology  (named  ACIS)  and  Unigraphics 
(named  Parasolid)  may  facilitate  two-dimensional  and  three-dimensional  transla¬ 
tion.  To  our  knowledge,  however,  no  CAD  software  offers  a  translator  for  the 
two-dimensional  STEP  format,  even  though  it  is  defined  by  international  standard. 

In  practice,  few  translators  are  completely  accurate  for  all  products;  they  require 
validation  and  cleanup  after  translation.  Similarly,  validation  and  cleanup  may  be 
required  when  upgrading  a  file  between  revisions  of  a  single  vendor’s  software. 
CAD  software  features  frequently  change,  and  new  software  versions  are  not  al¬ 
ways  completely  backward-compatible. 

Compared  to  raster  format,  two-dimensional  vector  format  adds  some  intelli¬ 
gence,  but  little  value  to  product  data.  Two-dimensional  geometry  that  is  easily 
edited  is  of  limited  suitability  for  CAM  applications.  Two-dimensional  geometry 
is  sufficient  for  parts  that  are  essentially  two-dimensional  (e.g.,  flat  sheet  metal)  or 
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are  symmetric  in  the  third  dimension  (e.g.,  tubes),  but  parts  with  three- 
dimensional  features  generally  must  be  entered  into  three-dimensional  format  be¬ 
fore  generating  machine  instructions. 

Three-Dimensional,  Proprietary,  Vector 
Format 


Three-dimensional  vector  formats  extend  the  idea  of  two-dimensional  formats. 
They  can  create  wire-frame,  surface,  and  solid  models.  Models  are  collections  of 
three-dimensional  object  representations,  such  as  blocks,  cylinders,  slots,  holes, 
and  lofted  shapes.  By  choosing  plan,  elevation,  and  side  views,  many  CAD  pack¬ 
ages  can  create  traditional-looking  two-dimensional  images  from  these  three- 
dimensional  models.  The  resulting  data  are  more  useable  by  other  functions,  such 
as  simulation-based  design  and  manufacturing  using  numerical-control  machine 
tools.  Three-dimensional  models  in  proprietary  format  use  a  file  structure  that  is 
specific  to  the  CAD  software  vendor  and  that,  in  general,  cannot  be  read  directly 
by  other  CAD  programs. 

Operational  Scenario 

Under  the  strategy  described,  DoD  would  acquire  product  data  from  the  initial  de¬ 
signer  and  store  them  in  a  three-dimensional,  proprietary,  vector  format.  DoD 
could  standardize  on  a  format  and  require  delivery  in  that  format,  or  it  could  stan¬ 
dardize  and  convert  the  data  itself  if  necessary.  Alternatively,  DoD  could  support 
several  proprietary  formats  and  store  the  data  in  the  format  in  which  they  were 
developed.  When  the  need  to  procure  arises,  the  DoD  buying  agency  would  re¬ 
trieve  and  distribute  the  data  as  electronic  file  attachments  to  the  request  for  quo¬ 
tation.  Here,  too,  DoD  could  distribute  the  data  as-stored  or  convert  them  to  a 
format  requested  by  the  contractor. 

To  generate  a  quote,  the  contractor  would  perform  the  following  tasks: 

♦  Generate  a  bill  of  materials. 

♦  Generate  a  routing  for  manufacturing  operations. 

♦  Identify  tools  and  fixtures. 

♦  If  necessary,  convert  the  product  data  file  to  the  contractor’s  CAM  soft¬ 
ware  format  and  verify,  correct,  or  regenerate  model  geometry. 

♦  Using  CAM  software,  create  a  cutting  tool  path  from  the  DoD-provided 
computer  model. 

♦  Develop  the  quotation. 
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Note  that  the  need  to  generate  a  computer  model  is  eliminated  because  that  model 
would  be  provided  by  DoD  as  part  of  the  request  for  quotation  package.  As  with 
the  prior  strategies,  some  contractors  may  develop  quotations  using  parametric 
equations  or  rules  of  thumb,  in  which  case,  some  of  the  tasks  above  would  take 
place  after  award.  Also,  some  or  all  of  the  above  tasks  might  not  be  necessary  if 
the  contractor  previously  had  built  the  part  and  had  saved  the  information  from  the 
earlier  contract.  Following  award  of  a  contract  or  delivery  order,  the  contractor 
would 

♦  acquire  or  design  and  build  tooling  and  fixtures, 

♦  generate  numerical  control  code  (machine-tool  instructions), 

♦  postprocess  numerical  control  code, 

♦  schedule  the  job,  and 

♦  make  the  parts. 

These  last  steps  are  unchanged  from  the  earlier  strategies. 

Economic  Issues 

Providing  contractors  three-dimensional  product  data  would  reduce  the  time  and 
effort  required  to  generate  process  plans  and  machine  instructions.  The  greater 
amount  of  data  contained  in  three-dimensional  models  improves  vendors’  ability 
to  produce  the  proper  part.  Also,  in  some  cases,  it  is  less  costly  to  develop  three- 
dimensional  geometry  using  constructive  solid  geometry  techniques  than  to  de¬ 
velop  two-dimensional  geometry. 

This  strategy  has,  however,  several  economic  disadvantages.  Three-dimensional 
systems  generally  are  more  expensive  to  acquire  (software)  and  require  more 
powerful  computers  (hardware)  than  two-dimensional  systems.  Three-dimensional 
product  data  may  also  consume  ihore  storage  space  than  two-dimensional  data  and 
may  require  more  initial  training. 

One  perception  among  government  officials  is  that  small  manufacturing  busi¬ 
nesses  cannot  afford  and  are  not  technically  savvy  enough  to  operate  advanced 
mechanical  engineering  software.  While  we  have  not  performed  a  systematic  sur¬ 
vey,  our  experience  indicates  that  many  small  businesses  are  using  this  software 
successfully.  However,  choosing  a  single  proprietary  format  may  impose  a  burden 
on  some  contractors  and,  at  the  same  time,  exclude  others. 
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Technical  Issues 

Three-dimensional  product  modeling  represents  the  state-of-the-art  in  mechanical 
design.  Graphic  visualization  improves  process  planning,  computer  numerical 
control  programming,  and  quality  assurance.  Unambiguous  solid  representation  is 
necessary  for  semi  automated  and  automated  computer-aided  process  planning 
systems.  Also,  with  some  CAD  user  interfaces,  it  is  easier  to  generate  a  three- 
dimensional  solid  than  multiple  two-dimensional  views. 

Using  three-dimensional  data  would  enable  DoD  to  take  advantage  of  numerous 
robust  software  systems  that  are  commercially  available.  From  a  data  quality 
standpoint,  it  is  generally  best  to  maintain  a  drawing  in  the  environment  in  which 
it  was  developed.  Also,  many  CAD  systems  are  integrating  analysis,  kinematics, 
product  data  management,  manufacturing,  and  assembly  capabilities  into  their 
products.  By  providing  its  contractors  with  data  already  in  three-dimensional  for¬ 
mat,  DoD  would  be  getting  easier  access  to  these  capabilities. 

The  use  of  proprietary  data  formats  would  pose  a  challenge  to  DoD.  DoD  often 
procures  products  and  their  technical  data  initially  from  one  source  and  later  re¬ 
procures  the  products  from  another  source.  Dealing  with  a  large  vendor  base,  as 
DoD  does,  almost  guarantees  that  it  would  receive  data  in  several  CAD  formats. 
To  store  such  data  in  a  single  format,  or  to  translate  those  data  to  another  vendor’s 
format,  would  require  special  translators  or  neutral  file  formats. 

Three-Dimensional,  Neutral,  Vector  Format 

Product  data  in  three-dimensional,  neutral  vector  format  are  those  created  in  a 
proprietary  format  but  then  stored  in  a  standard  format  that  can  be  read  by  any 
program  adhering  to  the  standard.  The  standard  format  can  be  de  facto,  such  as  the 
ACIS  and  Parasolid  modeling  engines,  or  formal,  such  as  ANSI/US  PRO/IPO 
100-1996,  Initial  Graphics  Exchange  Specification  IGES  5.3  (IGES)  and  the  ISO 
10303  series  entitled  Industrial  Automation  Systems  and  Integration— Product 
Data  Representation  and  Exchange. 

Operational  Scenario 

Under  this  strategy,  DoD  would  acquire  product  data  in  a  three-dimensional,  neu¬ 
tral,  vector  format  from  the  initial  designer  and  store  them  in  that  same  format.  If 
the  format  were  truly  neutral  and  universally  available,  DoD  could  require  deliv¬ 
ery  in  that  format  without  adding  materially  to  the  original  designer’s  effort. 

When  the  need  to  procure  arises,  the  DoD  buying  agency  would  retrieve  and  dis¬ 
tribute  the  neutral-format  data  as  an  electronic  file  attachment  to  the  request  for 
quotation. 
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To  generate  a  quote,  the  contractor  would  perform  the  following  tasks; 

♦  Generate  a  bill  of  materials. 

♦  Generate  a  routing  for  manufacturing  operations. 

♦  Identify  tools  and  fixtures. 

♦  Convert  the  neutral  product  data  file  to  the  CAM  software  format  and  ver¬ 
ify,  correct,  or  regenerate  model  geometry. 

♦  Using  CAM  software,  create  a  cutting  tool  path  from  the  DoD-provided 
computer  model. 

♦  Develop  the  quotation. 

Note  that  the  need  to  generate  a  computer  model  is  eliminated  because  that  model 
would  be  provided  by  DoD  as  part  of  the  Request  for  Quotation  package.  Also, 
the  conversion  to  the  contractor’s  CAM  software  format  may  be  eliminated  if  that 
software  supports  the  neutral  format.  As  with  the  prior  strategies,  some  contrac¬ 
tors  may  develop  quotations  using  parametric  equations  or  rules  of  thumb,  in 
which  case,  some  of  the  tasks  above  would  take  place  after  award.  Also,  some  or 
all  of  the  tasks  above  might  not  be  necessary  if  the  contractor  had  built  the  part 
before  and  had  saved  the  information  from  the  earUer  contract.  The  steps  follow¬ 
ing  a  contract  or  delivery  order  award  would  be  unchanged  from  the  three- 
dimensional,  proprietary,  vector  format  strategy  described  above. 

Economic  Issues 

The  key  advantage  of  the  neutral  file  concept  is  that,  in  theory,  it  would  enable 
DoD  to  store  its  product  data  in  one  format  and  it  would  allow  DoD’s  vendors  to 
read  those  data  regardless  of  what  software  product  they  use.  Data  conversion  er¬ 
rors  and  model  reconstruction  could  be  greatly  reduced.  These  advantages  would 
mean  that  vendors  could,  with  less  time  and  labor,  convert  DoD’s  product  data 
into  manufactured  goods. 

Given  that  software  vendors  supply  translators  to  the  neutral  format,  this  strategy 
would  involve  no  more  hardware  or  software  cost  than  the  three-dimensional, 
proprietary,  format  strategy,  because  it  would  use  the  vendors’  existing  systems.  It 
could  even  reduce  costs  for  manufacturers  who  are  now  maintaining  multiple 
CAD  platforms. 

Technical  Issues 

While  the  promise  of  neutral  format  exchange  between  CAD  systems  is  very 
powerful,  the  standards  defining  those  formats  are  immature  and  not  yet  fully 
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supported  by  CAD  software  providers.  While  many  CAD  packages  support  IGES, 
that  standard  does  not  provide  for  complete  and  accurate  product  representation. 
STEP  is  less  mature.  Only  3  of  the  approximately  30  application  protocols  defin¬ 
ing  product  data  within  STEP  have  been  designated  international  standards  (the 
remainder  are  in  various  stages  of  draft  and  committee  review).  Of  the  main  ap¬ 
plication  protocols  relating  to  the  design  of  mechanical  parts,  one  is  an  interna¬ 
tional  standard:  ISO  10303-203:1994,  Industrial  Automation  Systems  and 
Integration — Product  Data  Representation  and  Exchange — Part  203:  Application 
protocol:  Configuration  controlled  design.  That  standard  defines  nominal  three- 
dimensional  geometry.  Most  CAD  software  vendors  do  provide  translators  for 
AP203.  This  standard  does  not,  however,  contain  sufficient  data  to  manufacture  a 
part.  It  lacks  both  tolerances  and  supporting  text  information  (e.g.,  material  speci¬ 
fications  and  process  notes).  The  second  application  protocol,  tentatively  named 
Industrial  Automation  Systems  and  Integration — Product  Data  Representation 
and  Exchange— Part  224:  Application  Protocol:  Mechanical  Parts  Definitions  for 
Process  Planning  Using  Machining  Features,  promises  to  address  these  shortfalls. 
Unfortunately,  that  standard  has  not  yet  been  approved  and  no  software  vendors 
support  it  yet.’ 

Even  if  the  standards  were  mature  and  supported  by  the  CAD  industry,  their  ad¬ 
vantage  would  not  be  clearcut.  Computer  modeling  systems’  capabilities  are  very 
complex  and  are  undergoing  continuous  development.  The  introduction  of  new 
features  and  capabilities  is  central  to  the  competitiveness  of  the  CAD  industry. 
Given  the  slow  pace  of  STEP,  it  is  questionable  whether  the  development  of  a 
standard  exchange  protocol  can  keep  pace.  For  example,  STEP  AP224,  even  if 
implemented,  will  not  support  parametric  design,  which  is  a  recent  but  widely 
available  CAD  capability. 

Three-Dimensional,  Neutral,  Machine 
Instructions 

All  of  the  product  data  strategies  previously  described  center  around  the  format  of 
the  product  model  itself.  Three-dimensional,  neutral,  machine  instructions  would 
store  the  process  to  make  the  product.  This  strategy  would  require  an  accompa¬ 
nying  product  model,  probably  in  a  three-dimensional  format.  The  strategy  proba¬ 
bly  would  be  limited  to  mechanical  parts  that  can  be  made  by  computer-controlled 
machine  tools  using  standard  fixtures  and  tooling.  While  machine  tool  controllers 
are  not  standardized,  standards  do  exist  for  the  transfer  of  instructions  from  CAM 
software  to  the  machine  tools.  Two  such  standards  are  ANSI/EIA  274-D-1980 
(R1988),  Interchangeable  Variable  Block  Data  Format  for  Positioning,  Con¬ 
touring,  and  Contouring/Positioning  Numerically  Controlled  Machines  and 
ANSI/EIA  494-B-1992,  32-Bit  Binary  CL  (BCL)  and  7-Bit  ASCII  CL  (ACL)  Input 


’  The  South  Carolina  Research  Authority  has,  under  the  sponsorship  of  DoD,  developed  an 
AP224  translator  for  Pro/Engineer. 
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Format  for  NCM.  Instructions  in  these  standard  formats  must  be  run  through 
widely  available  “post-proeessors”  to  customize  them  to  the  input  format  required 
by  the  particular  machine  tool  and  controller  to  be  used. 

Operational  Scenario 

This  strategy  would  transfer  manufacturing  engineering  (i.e.,  proeess  planning,  the 
activity  required  to  translate  a  design  into  manufacturing  instructions)  from  a  re¬ 
curring  activity  (and  cost)  to  a  nonrecurring  activity.  Under  this  strategy,  DoD 
would  acquire  produet  data  in  a  three-dimensional,  vector  format  (proprietary  or 
neutral)  from  the  original  manufacturer.  The  original  designer,  a  private-sector 
service  bureau  or  DoD  would  perform  the  contractor’s  pre  award  manufacturing 
engineering  steps  listed  under  strategies  previously  described  as  follows: 

♦  Generate  a  bill  of  materials. 

♦  Generate  routings  for  manufacturing  operations. 

♦  Identify  fixtures,  tooling  types,  sizes,  speeds,  and  feeds. 

♦  Create  a  tooling  path. 

In  addition,  the  manufacturing  engineering  activity  would  create  a  eutter  location 
data  file  in  one  of  the  standard  formats  listed  in  the  introduction  to  this  section. 
DoD  would  take  delivery  of  the  product  data  (i.e.,  CAD)  file  and  tiie  cutter  loca¬ 
tion  (i.e.,  CAM)  file  and  archive  those  files.  When  the  need  to  procure  arises,  the 
DoD  buying  agency  would  retrieve  and  distribute  both  files  as  electronic  attach¬ 
ments  to  the  request  for  quotation. 

To  generate  a  quotation,  the  contractor  would  review  the  product  data  file  and 
cutter  loeation  file  and  estimate  his  costs  based  on  material  requirements  and  the 
provided  process.  The  format  of  the  product  data  file  is  not  of  particular  impor¬ 
tance  to  this  strategy,  because  almost  all  major  CAD  vendors  provide  either  free 
or  nominal-cost  software  with  which  their  models  can  be  viewed  and  printed  (but 
not  edited). 

Upon  award,  the  contractor  would  acquire  tooling  and  fixtures  (if  necessary  be¬ 
cause  this  approaeh  depends  on  the  use  of  standard  tooling  and  workholding)  and 
feed  the  cutter  location  file  into  post-processing  software.  The  contractor  then 
would  need  to  link  the  tools  in  the  machine  instruetion  file  to  the  specific  machine 
tool’s  tooling  list.  If  it  were  necessary  to  ehange  the  standard  process,  the  numeri¬ 
cal  code  could  be  easily  reprogrammed.  For  example,  the  sequence  of  operations 
could  be  altered  by  simple  “cutting  and  pasting”  in  the  eontrol  file. 
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Economic  Issues 

This  strategy  appears  attractive  because  it  eliminates  the  issue  regarding  in  what 
format  to  provide  a  product  model  to  manufacturers.  DoD  could  maintain  product 
data  in  any  three-dimensional  format  that  it  chooses  because  almost  all  proprietary 
formats  can  be  inexpensively  viewed  by  manufacturers.  DoD  may  get  reduced 
prices  because  it  would  only  buy  machine  hours  from  vendors,  having  already 
paid  for  manufacturing  engineering.  Similarly,  production  lead-times  might  be 
lower  because  of  the  elimination  of  engineering  time.  However,  because  the 
“standard”  process  plan  and  machine  instructions  selected  by  DoD  (or  its  service 
bureau)  might  not  be  optimal  for  any  given  manufacturer,  the  manufacturing  por¬ 
tion  of  part  prices  could  be  higher. 

Technical  Issues 

The  technical  challenges  posed  by  this  strategy  are  significant  and  have  not  been 
shown  to  be  feasible  in  a  regular  procurement  environment.  First,  it  is  likely  that  a 
computer  numerical  control  program  of  any  complexity  will  have  programming 
errors.  This  could  pose  problems  for  manufacturers  (and  increase  cost),  because  it 
is  much  more  difficult  to  debug  someone  else’s  program.  DoD  cannot  respond 
quickly  today  to  manufacturer’s  questions  on  two-dimensional  blueprints,  and  so 
it  may  not  be  able  to  respond  quickly  to  future  questions  regarding  machine  tool 
instructions.  The  risk  would  be  minimized,  however,  if  DoD  took  delivery  of  a 
validated  part  along  with  the  part  data. 

Second,  it  will  be  difficult  to  stay  current  with  new  tooling  and  fixturing.  These 
factors  can  have  a  significant  impact  on  the  tool  path  used,  on  machine  speeds  and 
feeds,  and  ultimately  on  product  cost.  Finally,  DoD  would  need  a  format  and  pro¬ 
cedure  by  which  to  communicate  routing,  tool,  and  fixture  plans  with  the  machine 
instructions. 
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Chapter  4 

Findings,  Conclusions,  and  Recommendations 


On  the  basis  of  our  market  survey  of  CAD/CAM  capabilities  and  the  capabilities 
of  IGES  and  STEP,  we  summarize  our  findings  and  conclusions: 

♦  The  CAD/CAM  software  market  offers  many  advanced  capabilities,  in¬ 
creasing  integration  among  products,  and  is  evolving  rapidly  due  to  com¬ 
petition. 

♦  The  mechanical  engineering  software  industry  is  consolidating,  making  it  a 
bit  easier  to  identify  the  leading  vendors.  Six  companies — ^Parametric 
Technology  Corporation,  Dassault  Systemes,  SDRC,  AutoDesk,  Uni¬ 
graphics,  and  CADAM  Systems — accounted  for  70  percent  of  1997  in¬ 
dustry  sales. 

♦  DoD,  by  establishing  standard  practices  built  around  raster  format,  is  los¬ 
ing  product  data  created  by  its  manufacturers  in  CAD  or  is  being  forced  to 
capture  those  data  in  other  less  efficient  formats. 

♦  Today,  STEP  can  handle  only  part  of  DoD’s  product  data  storage  needs, 
specifically,  only  nominal  three-dimensional  geometry.  Commonly  used 
capabilities,  such  as  parametrics,  design  constraints,  and  product  data 
management,  are  not  in  any  near-term  STEP  implementation  plans. 

♦  The  STEP  APs,  if  completed  and  adapted  by  industry,  would  dramatically 
simplify  DoD’s  tasks  of  storing,  maintaining,  and  distributing  data  for 
competitively  procured  items. 

♦  Commercial  industry,  while  hopeful  for  STEP,  is  not  waiting.  They  ex¬ 
change  data  in  proprietary  formats  and  in  IGES  and  use  point-to-point 
translators.  Exchanges  are  not  perfect,  but  the  benefits  of  state-of-the-art 
CAD  outweigh  the  effort  required  to  clean  up  transferred  data. 

On  the  basis  of  our  findings  and  conclusions,  we  recommend  these  actions: 

♦  DoD  should  formally  recognize  the  immaturity  of  STEP  and  adopt  interim 
advanced  product  data  formats.  We  recommend,  as  appropriate  to  the  par¬ 
ticular  commodity  and  product  in  question,  the  two-dimensional  and  three- 
dimensional  vector  approaches  outlined  above. 
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♦  DoD  still  should  support  the  development  of  STEP  and  await  its  eventual 
widespread  acceptance.  As  STEP  APs  mature,  DoD  should  validate  that 
they  indeed  store  the  data  DoD  needs  and  develop  a  transition  plan  away 
from  proprietary  formats. 

♦  DoD  should  conduct  a  survey  to  determine  what  specific  product  data 
formats  (i.e.,  CAD  software  packages)  its  current  and  potential  suppliers 
use  most.  The  survey  should  determine  which  formats  the  suppliers  would 
prefer  DoD  to  use  and  which  they  would  accept  if  necessary. 

♦  DoD  should  conduct  an  internal  survey  to  determine  what  product  data 
formats  it  is  capable  of  creating  and  maintaining  within  military  service 
and  DLA  engineering  activities. 

♦  DoD  should  more  fully  use  the  JEDMICS  capability  to  store  and  retrieve 
files  of  any  format  and  configure  users  to  enable  that  capability.  The 
JEDMICS  capability  should  include  the  commercially  available  viewers 
for  common  CAD  formats,  and  it  should  also  consider  the  increasingly 
available  Internet  browser-based  viewers. 

♦  For  hardware  procurements  in  which  DoD  today  implicitly  pays  contrac¬ 
tors  to  produce  “smart”  CAD  data  from  “dumb”  raster  data,  DoD  should 
take  delivery  of  CAD  data  along  with  the  hardware.  This  practice  would 
apply  to  competitively  procured  items,  and  it  would  depend  on  DoD’s 
ability  to  validate  the  data  and  store  them  within  JEDMICs. 

♦  DoD  should  form  a  cross-functional  government  and  industry  team  to  de¬ 
termine  the  most  technically  feasible  and  affordable  approach  for  main¬ 
taining  capability  (both  human  and  machine)  in  multiple  product  data 
formats. 

♦  The  DoD  team  should  define  how  to  handle  CAD/CAM  software  upgrades 
and  file  revisions.  That  team  should  first  survey  how  large  commercial 
firms  (for  example,  the  conunercial  aircraft  and  automotive  industries)  at¬ 
tack  the  problem. 

♦  DoD  should  recognize  that  no  single  format  will  suit  all  of  its  needs  and 
that  the  formats  it  uses  will  change  over  time  as  software  capabilities 
evolve.  Economic  considerations,  the  conunodity  being  represented,  and 
the  state  of  CAD/CAM  for  the  commodity  will  dictate  how  advanced  the 
format  is  that  DoD  can  feasibly  maintain.  Flexibility  and  the  ability  to 
adapt  new  formats  over  time  will  be  key. 

♦  DoD  should  conduct  a  feasibility  study  of  the  three-dimensional,  neutral, 
machine  instructions  alternative. 
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Product  Data  Alternatives 


One  approach  for  comprehensively  addressing  these  recommendations  would  be 
to  organize  an  Advanced  Technology  Concept  Demonstration  under  the  Defense 
Science  and  Technology  Program.  That  demonstration  could  be  managed  by  the 
Joint  Electronic  Commerce  Program  Office  with  participation  of  the  military 
services  and  the  Defense  Logistics  Agency. 
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